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Description Option for the Port Control Protocol (PCP) 
Abstract 
This document extends the Port Control Protocol (PCP) with the 
ability to associate a description with a PCP-instantiated mapping. 
It does this by defining a new DESCRIPTION option. 
Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7220. 
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to this document. Code Components extracted from this document must 
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1. Introduction 


This document extends the base PCP [RFC6887] with the ability to 
associate a human-readable description with a PCP-instantiated 
mapping. It does this by defining a new DESCRIPTION option. 


This PCP option can be used in simple scenarios with a PCP client and 
PCP server, as well as in more complex scenarios where an 
interworking function is used to proxy between a UPnP IGD Control 
Point and a PCP server [RFC6970]. 


Querying the PCP server to get the description text of an existing 
mapping is out of scope. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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2. Format 
The format of the DESCRIPTION option is shown in Figure 1. 


0 1 2 3 
Owl 23 4.75: 6°. 28" 9.0. 1.2 3° 45 6 7 89 0 123: 4 5 6 7 8 Oo OL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 

|Option Code=128| Reserved | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 
| Description | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
This Option: 


Option Name: DESCRIPTION 

Number: 128 

Purpose: Used to associate a text description with a mapping 

Valid for Opcodes: MAP, PEER 

Length: Variable, maximum 1016 octets. 

May appear in: request. May appear in response only if it 
appeared in the associated request. 

Maximum occurrences: 1 


Figure 1: DESCRIPTION Option 


The ’Reserved’ field is initialized as specified in Section 7.3 of 
[RFC6887]. 


The Description field MUST carry UTF-8 encoded [RFC3629] description 
text. The description text MUST NOT be null terminated. The length 
of the description text is indicated by the Length field. In 
particular, the description text is not null terminated, and when a 
client or server receives a DESCRIPTION option, it MUST NOT rely on 
the presence of a NUL character in the wire format data to identify 
the end of the text. 


This option can be used by a user (or an application) to indicate a 
description associated with a given mapping, such as "FTP server", 
"My remote access to my CP router", "Camera", "Network attached 
storage serve", etc. 
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How the content of the DESCRIPTION option is used is deployment- 
specific. For example, the description text can be used by the 
entity managing the PCP server for many purposes, such as the 
following: 


o The description text can be used as a hint when cleaning a mapping 
table by an administrator. 


o In some deployments making use of a portal to instruct PCP 
mappings (e.g., Section 5.2 of [PCP-DEPLOY]), the description text 
can be used to store a subscriber identifier. 


3. Behavior 


Support for the DESCRIPTION option by PCP servers and PCP clients is 
optional. This option (Code 128; see Figure 1) MAY be included in a 
PCP MAP/PEER request to associate a description with the requested 
mapping. 


A PCP server MAY ignore the DESCRIPTION option sent to it by a PCP 
client (e.g., if it does not support the option or if it is 
configured to ignore it). To signal that it has not accepted the 
option, a PCP server simply does not include the DESCRIPTION option 
in the response. If the PCP client does not receive a DESCRIPTION 
option in a response to a request enclosing a DESCRIPTION option, 
this means the PCP server does not support the option or it is 
configured to ignore it. 


If the DESCRIPTION option is not included in the PCP client request, 
the PCP server MUST NOT include the DESCRIPTION option in the 
associated response. 


A PCP server SHOULD be able to store at least 128 bytes fora 
description. When the PCP server receives a DESCRIPTION option, it 
first stores the value of the received Description field, truncating 
it if it cannot store the entire value. The server MUST then send 
the stored value back to the PCP client in the DESCRIPTION option in 
the response. 


If the PCP client request contains invalid DESCRIPTION options (e.g., 
the content is not a legal UTF-8 string), the PCP server MUST ignore 
the request (i.e., MUST NOT return a DESCRIPTION option in the 
response). 


To update the description text of a mapping maintained by a PCP 
server, the PCP client generates a PCP MAP/PEER renewal request that 
includes a DESCRIPTION option carrying the new description text. 
Upon receipt of the PCP request, the PCP server proceeds to the same 
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6. 


6. 


t; 


operations to validate a MAP/PEER request refreshing an existing 
mapping. If validation checks are successfully passed, the PCP 
server replaces the old description text with the new one included in 
the DESCRIPTION option, and the PCP server returns the updated 
description text in the response, truncated (if necessary) as 
described above. 


The PCP client uses an empty DESCRIPTION option (i.e., Length set to 
0) to erase the description text associated with a mapping. To 
indicate that the PCP server has successfully cleared the description 
text associated with a mapping, the PCP server returns the empty 
DESCRIPTION option in the response. 


Security Considerations 


PCP-related security considerations are discussed in [RFC6887]. In 
addition, administrators of PCP servers SHOULD configure a maximum 
description length that does not lead to exhausting storage resources 
in the PCP server. 


If the PCP client and the PCP server are not under the same 
administrative entity, the DESCRIPTION option has the potential to 
leak privacy-related information. PCP clients should not use the 
DESCRIPTION option for such leakage. For example, the option should 
not be used to include user identifiers, locations, or names. Refer 
to Section 3.2 of [RFC6462] for a discussion on information leakage. 


TANA Considerations 
TANA has allocated the following value in the "PCP Options" registry 
(http://www.iana.org/assignments/pcp-parameters) from the optional- 
to-process range (see Section 19.4 of [RFC6887]): 
DESCRIPTION set to 128 (see Section 2) 
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